home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16509 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.9 KB
  1. Path: line115.nwm.mindlink.net!user
  2. From: emery@grebyn.com (David Emery)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: Wed, 10 Apr 1996 20:23:35 +0100
  6. Organization: MIND LINK! - British Columbia, Canada
  7. Message-ID: <emery-1004962023350001@line115.nwm.mindlink.net>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com> <dewar.829011320@schonberg> <4kcsnsINNgkb@keats.ugrad.cs.ubc.ca> <dewar.829051685@schonberg> <829066525snz@genesis.demon.co.uk> <dewar.829096975@schonberg>
  9. NNTP-Posting-Host: line115.nwm.mindlink.net
  10.  
  11. In article <dewar.829096975@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote:
  12.  
  13. ...
  14. > What exactly *is* the wording of the POSIX standard here (Lawrence, you
  15. > must have it at hand, please quote it exactly). The interesting thing
  16. > is to determine whether this definition says enough to make *any* use
  17. > of read defined without appealing to "unwritten rules". I would guess
  18. > not!
  19.  
  20. I checked today.  POSIX.1 (1995 version) is completely silent about
  21. what happens when the count > the length of buf.  I wish I brought my
  22. standard home, so I could quote it, but it says something like "read transfers 
  23. count characters into the buffer pointed to by buf."  The standard
  24. is completely silent about the characteristics of buf, and one could do
  25. some 'formal standards reasoning' that says that *any* program that
  26. depends on the relationship between buf and count is non-compliant, in that
  27. it is depending on unspecified behavior.
  28.  
  29. One would have expected for the standard to say something like 
  30. "the buffer pointed to by buf, which is expected to be capable of
  31. holding at least count bytes..."  Oftentimes, POSIX is deliberately silent
  32. in some areas, particularly error handling, because there was no consensus
  33. on behavior.  Thus any behavior is "undefined", and any implementation is
  34. 'conforming', regardless of what it does.  Personally, I think it's very
  35. poor standardization practice to be silent in such cases, I'd much prefer
  36. the standard to explicitly specify such behaviors as 'undefined', to
  37. warn the user.  In this case, I would have preferred for POSIX.1 to say
  38. "If the size of the storage area pointed to by buf exceeds the value of
  39. count, the results of any transfer into buf is unspecified."
  40.  
  41. Additionally, there is no explicit error code identified for "too much
  42. stuff in the buffer".  But POSIX.1 permits implementation extensions in
  43. such a circumstance, so the Linux implementation is perfectly conforming,
  44. as are implementations that blindly write into some other address space
  45. and implementations that detect the fault and immediately send email
  46. to CJIII and his lawyer :-)  
  47.  
  48. (Even in Ada, writing past the end of an array using unchecked programming
  49. can result in any sort of behavior, including trashing the boot track of
  50. the system disk....)
  51.  
  52.                dave
  53.